With contemporary operating systems, such as Microsoft Corporation's Windows® XP operating system with an underlying file system such as the Windows® NTFS (Windows® NT File System), FAT, CDFS, SMB redirector filesystem, or WebDav file systems, one or more file system filter drivers may be inserted between the I/O manager that receives user I/O requests and the file system driver. In general, filter drivers (‘filters’) are kernel-mode drivers that enhance the underlying file system by performing various file-related computing tasks that users desire, including tasks such as passing file system I/O (requests and data) through anti-virus software, file system quota providers, file replicators and encryption/compression products. For example, antivirus products provide a filter that watches I/O to and from certain file types (.exe, .doc, and the like) looking for virus signatures, while file replication products perform file system-level mirroring. Other types of file system filter drivers are directed to system restoration (which backs up system files when changes are about to be made so that the user can return to the original state), disk quota enforcement, backup of open files, undeletion of deleted files, encryption of files, and so forth. Thus, by installing file system filter drivers, computer users can select the file system features they want and need, in a manner that enables upgrades, replacement, insertion, removal of the components without necessitating the changing the actual operating system or file system driver code.
The existing file system filter model in contemporary Windows®-based operating systems (e.g., Windows® NT, Windows® 2000, Windows® XP, Windows®.NET Server 2003) leverages the inherent I/O model, which is a packet-based approach. To this end, file system filters load as regular drivers in a stack and attach to the underlying file system's volume device objects. User I/O requests are converted by an I/O manager into I/O Request Packets (IRPs), which are sent to the driver stack and processed by the top driver, which may complete it, pass it down in a call to another driver towards the file system, which calls the next lower driver, and so on. In general, each driver does whatever processing it is coded to perform on the IRP, and then explicitly passes down the IRP to the next lower driver (or file system if none are lower), or completes (or fails) the IRP and sends it back up the stack to the next higher driver (or the I/O manager if none are higher).
Although this existing filter driver model provides a number of benefits including being highly flexible, there are also a number of inherent problems with it. For one, writing a file system filter is a non-trivial task, primarily as a result of the underlying complexity of a file system. Filters are highly complex pieces of software that are traditionally hard to debug and maintain. Much of the complexity arises from the filters' handling of the packets, e.g., the need to understand and manipulate IRPs. As a result, reliability suffers, and at least one study has shown that filters have been responsible for a significant percentage of system crashes.
Another problem is efficiency, as file system filters traditionally receive and process every operation that normally goes to a file system, even those in which they have no interest in. For example, an antivirus product can slow down a system as much as sixty percent, but not every I/O request received by an antivirus filter is one that the filter will do anything with, namely inspect any corresponding data for viruses. Redundancy is also a problem that leads to inefficiency and computing cost, as many filters do the same things in different ways, leading to unnecessary code.
Interoperability between drivers is also a significant problem, as, for example, one driver may modify I/O in a way that the other driver does not anticipate and cannot properly deal with. Note that interoperability problems are one of the biggest drawbacks of the existing model, in part because filters have only a very coarse-grained control over attachment ordering to a file system.
Other problems include overflowing stack space, because when two or more filters are installed, stack overflows are common due to recursive reentrant I/O issued by filters. Deadlocks are also common in the existing model, again primarily due to re-entrant I/O. Other problems include the inability to dynamically load and unload filters in the stack, that is, without a system reboot.
In sum, the existing filter driver model has a number of significant drawbacks. What is needed is an improved model and architecture for file system filters to handle file system I/O requests and associated data.